随笔分类
对 Redis哨兵机制的些许思考:
# *主从库切换时,客户端能否正常地进行请求操作
- *如果客户端使用了读写分离,那么读请求可以在从库上正常执行,不会受到影响;但由于此时主库已经挂了,并在哨兵没有完成主从库的切换,因此这期间过来的写请求,都会失败,失败持续时间:哨兵切换主从时间 + 客户端感知到新主库的时间
- 如果不想然业务感知到异常,客户端可以去把写失败的请求缓存起来或写入消息队列中间件中,等哨兵完成主从切换后,再将这些写请求发送给新的主库,但这种一般只适用于对写入请求返回值不敏感的业务(不然可能读取到的便是旧的数据)
- 如果主从切换时间过长,那么缓存的写请求就会过多,主从切换之后重放这些请求的时间也会变长
# *如果想要应用程序不感知服务的中断,还需要哨兵或需要应用程序在做些什么吗 ?
- *当哨兵完成主从切换后,客户端应该及时感知到主库发生了变更,并且去将缓存起来的写操作以及后续会来的写请求都写入新主库中去,依赖保证服务的正常处理
# *引入哨兵集群后,需要考虑的问题有哪些 ?
- *哨兵与哨兵之间关系的确立,哨兵本身配置时未去配置彼此间的连接信息
- 基于 pub/sub机制的哨兵集群的组成建立
- 哨兵与从库之间关系确立
- 基于 INFO命令的从库列表,开帮助哨兵和从库建立连接
- 哨兵与客户端之间关系确立
- 基于哨兵自身的 pub/sub机制,来实现客户端和哨兵之间的事件通知
# *哨兵集群数量为什么通常会去配置至少三个哨兵实例(或者说是至少是 > 1的奇数个哨兵实例)?
- *我们知道,判定主库是否是 "客观下线",是通过哨兵集群来投票进行的,而哨兵集群能够进行成功投票与选举(Leader的选举),很大程度上依赖于选举命令的正常网络传播;
如果网络压力过大,或者存在短时阻塞,就可能导致没有一个哨兵能拿到半数以上的赞成票,因此,需要等到网络拥塞好转之后,再去进行重新投票的过程,这样的话投票的概率就会增加,即对应的便是存在一个等待时间(哨兵故障转移超时时间的两倍)
- 但,固然网络通畅,我们也需要来考虑集群中哨兵实例数量
- 一方面便是出于判定误差率减小的概率,我们希望哨兵实例数量不能太少
- 其次,出于哨兵可能故障挂掉的考虑,为了集群稳定性,哨兵数量也不能太少
- 然后,若是网络通畅,哨兵完好下,出于成功实现投票(对于客观下线)以及 Leader的枚举的成功率的考虑,哨兵实例个数最好是奇数个,这样的话,不出意外一轮投票与选举便能确定出真正去进行主从切换的 Leader,这也避免了后续再去进行重新的投票与选举!
# *Leader的选举需要满足什么条件 ?这其中有没有什么是需要额外注意的 ?
- *当进行 Leader选举时,我们已经知道了主库已经挂掉了,即先进行主库 "客观下线"的判断,再去进行 Leader的投票选举
- 选举需要满足两个条件:
- a.获得半数以上的赞同票
- 对于这个条件,我们需要额外注意些许:这里的半数以上的赞同票,指的是集群中配置的哨兵实例个数,即包括了可能已经挂掉了的哨兵实例
- 因此,若是哨兵挂掉的太多了,可能 Leader就永远无法区选举出来
- 举个简单例子:配置了 5个哨兵实例的集群,其中 3个哨兵挂了,此时主库需要进行切换,你认为还能获得 (5 / 2 + 1 = 3)个赞同票吗 ?对吧,挺有意思的这块
- b.获得的赞同票大于等于配置文件中配置的 quorum值